Govern sharing of restricted data by observer verification - #340

Comments and the plan doc still described two-phase redemption: a failed
open reverting the redemption server-side, so a retry had to re-send the
key, and success "confirming" it. Under one-step redemption (#340) the
edge is real the moment the server redeems, so a failure after that
point retries keylessly and nothing is ever reverted or confirmed.

The mechanism is unchanged and still earns its keep: an open can fail
*before* the redemption lands (a transport failure, a server throw ahead
of the redemption, an attempt superseded before issuing), and the client
cannot distinguish that from a post-redemption failure, so it retains
the key on every failure -- replaying a key whose edge already exists is
a server-side no-op. Prose only; no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Comments and the plan doc still described two-phase redemption: a failed
open reverting the redemption server-side, so a retry had to re-send the
key, and success "confirming" it. Under one-step redemption (#340) the
edge is real the moment the server redeems, so a failure after that
point retries keylessly and nothing is ever reverted or confirmed.

The mechanism is unchanged and still earns its keep: an open can fail
*before* the redemption lands (a transport failure, a server throw ahead
of the redemption, an attempt superseded before issuing), and the client
cannot distinguish that from a post-redemption failure, so it retains
the key on every failure -- replaying a key whose edge already exists is
a server-side no-op. Prose only; no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Comments and the plan doc still described two-phase redemption: a failed
open reverting the redemption server-side, so a retry had to re-send the
key, and success "confirming" it. Under one-step redemption (#340) the
edge is real the moment the server redeems, so a failure after that
point retries keylessly and nothing is ever reverted or confirmed.

The mechanism is unchanged and still earns its keep: an open can fail
*before* the redemption lands (a transport failure, a server throw ahead
of the redemption, an attempt superseded before issuing), and the client
cannot distinguish that from a post-redemption failure, so it retains
the key on every failure -- replaying a key whose edge already exists is
a server-side no-op. Prose only; no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Comments and the plan doc still described two-phase redemption: a failed
open reverting the redemption server-side, so a retry had to re-send the
key, and success "confirming" it. Under one-step redemption (#340) the
edge is real the moment the server redeems, so a failure after that
point retries keylessly and nothing is ever reverted or confirmed.

The mechanism is unchanged and still earns its keep: an open can fail
*before* the redemption lands (a transport failure, a server throw ahead
of the redemption, an attempt superseded before issuing), and the client
cannot distinguish that from a post-redemption failure, so it retains
the key on every failure -- replaying a key whose edge already exists is
a server-side no-op. Prose only; no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Comments and the plan doc still described two-phase redemption: a failed
open reverting the redemption server-side, so a retry had to re-send the
key, and success "confirming" it. Under one-step redemption (#340) the
edge is real the moment the server redeems, so a failure after that
point retries keylessly and nothing is ever reverted or confirmed.

The mechanism is unchanged and still earns its keep: an open can fail
*before* the redemption lands (a transport failure, a server throw ahead
of the redemption, an attempt superseded before issuing), and the client
cannot distinguish that from a post-redemption failure, so it retains
the key on every failure -- replaying a key whose edge already exists is
a server-side no-op. Prose only; no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Comments and the plan doc still described two-phase redemption: a failed
open reverting the redemption server-side, so a retry had to re-send the
key, and success "confirming" it. Under one-step redemption (#340) the
edge is real the moment the server redeems, so a failure after that
point retries keylessly and nothing is ever reverted or confirmed.

The mechanism is unchanged and still earns its keep: an open can fail
*before* the redemption lands (a transport failure, a server throw ahead
of the redemption, an attempt superseded before issuing), and the client
cannot distinguish that from a post-redemption failure, so it retains
the key on every failure -- replaying a key whose edge already exists is
a server-side no-op. Prose only; no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Comments and the plan doc still described two-phase redemption: a failed
open reverting the redemption server-side, so a retry had to re-send the
key, and success "confirming" it. Under one-step redemption (#340) the
edge is real the moment the server redeems, so a failure after that
point retries keylessly and nothing is ever reverted or confirmed.

The mechanism is unchanged and still earns its keep: an open can fail
*before* the redemption lands (a transport failure, a server throw ahead
of the redemption, an attempt superseded before issuing), and the client
cannot distinguish that from a post-redemption failure, so it retains
the key on every failure -- replaying a key whose edge already exists is
a server-side no-op. Prose only; no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

…es (#308)

* Restricted data part 5: UI changes.

The Share modal no longer replaces itself with a "can't be shared" view when
the workspace has read restricted data. Sharing controls stay live and a
notice explains that collaborators must be able to see the data themselves.

The server allows sharing after the restricted latch (assertNewSharingAllowed
refuses only unverifiable producers) and GadgetMetadata.containsRestrictedData
documents that such a workspace can still be shared, so the modal's job is to
warn and to surface a server refusal verbatim -- which the existing toast
catches already do. Regression tests pin both: with the flag set, the banner
renders in place of the wall and every management affordance (invite, link
creation/copying, collaborator removal, link revocation) stays reachable; and
a server-side "can no longer be shared" rejection reaches the user as an
error toast.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Retain a consumed share key so a failed open can retry.

Opening with a #share= fragment strips the key from the URL, so an open that
failed while the recipient's access was still being verified had nothing left
to retry with. The key is now held and replayed on the next attempt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Bugfix: Identity-key retained share keys and clear them on logout.

The retained key moves to sessionStorage so a reload can still retry, which
means it can outlive the session that captured it. Each entry is therefore
stamped with the capturing user's id and ignored -- and swept -- when the
current session's id doesn't match, so one user's pending share key can never
be redeemed under the next user's account in the same tab.

logout() sweeps the whole prefix as well, including malformed and older
unstamped entries.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Bugfix: Abandon a superseded workspace open before it creates a capability.

The retained-storage path awaits identity resolution before openGadget. An
attempt superseded while parked there had already run its cleanup -- with
nothing yet to dispose -- so on resuming it minted a stub its cleanup can never
reach and published it over the replacement attempt's state: a stale
capability, or the wrong workspace's when the id changed.

Bail after the await, before any capability is created, like the checks the
later awaits already have.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Bugfix: Bind the retained share key to the session that captured it.

The in-memory retention tier carried no identity and was replayed on whatever
authenticated stub the effect ran with. Its safety rested on a rendering
invariant two files away -- that an identity change always unmounts the editor
-- which nothing local enforced; an account switcher or soft logout would have
silently turned it into a cross-user key replay.

The ref now records the stub that captured it and is replayed only on that
stub. Any other stub falls through to the sessionStorage tier, whose entries
are identity-stamped and checked. Stub identity rather than an async userId
keeps the common same-session retry pipelined.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Bugfix: Invalidate a pending share-key stamp on discard and logout.

The capture path's identity stamp is asynchronous, gated by a flag local to
one load attempt -- but the storage it writes is global. A stamp resolving
after a *different* attempt succeeded (or after logout swept the tier) wrote
the entry back, resurrecting a key that could silently re-redeem the
still-active link after an owner removes the collaborator.

Invalidation now lives in retainedShareKeys.ts as generation counters: a
capture takes a write token, and clearing a workspace's entry (or the logout
sweep) voids every token taken before it. The per-attempt flag is deleted --
its scope was the defect.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* Bugfix: Clear a retained share key as soon as the keyed open succeeds.

The server confirms a share-key redemption inside open(), before the client
holds the capability -- but retention was discarded only after
subscribeToMetadata resolved. That call has real post-open failure modes for
exactly the keyed audience (the non-owner whoami round trip, a WS drop), and
every error path keeps the key by design, so a confirmed-then-failed
subscribe left all three retry paths (retry button, reconnect stub swap,
remount) armed with a live key -- and a re-redemption after an owner removal
silently re-grants access, since links are multi-redeemable and owner removal
wipes edges but not the link.

Keyed opens now await the open promise (one extra round trip, keyed opens
only -- the pipelined RpcPromise stays usable as the stub) and discard both
retention tiers the moment success is knowable; an open failure rejects there
and keeps retention, matching the server's reverted redemption. The tail
clear stays for the keyless corner where a retained entry existed but was
not attached (the identity-unknown path). The denial tests now model the
denial where it really lands -- openGadget's promise rejecting -- rather
than as a subscribeToMetadata throw.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Bugfix: Don't let a superseded keyed open clear a newer attempt's retained key.

The finding-7 fix awaited the keyed open and then unconditionally discarded
both retention tiers -- with no cancelled check, unlike every other
side-effect site in the hook. The await can park across the attempt's
cancellation, and a superseded attempt no longer owns the retention state: a
newer attempt may have captured its own key -- possibly another user's, on a
swapped stub -- into the very ref and sessionStorage entry the late clear
wipes, and clearRetainedShareKey's write-token bump also permanently voids
that attempt's still-in-flight identity stamp, so its failed open dead-ends
unretryable.

Bail before the clears when cancelled, matching the hook's invariant
everywhere else. Skipping the clear loses nothing: replaying the superseded
attempt's confirmed key later is a server-side no-op (a confirmed edge skips
redemption), and whichever attempt next succeeds clears retention itself.
The stub was assigned before the await, so the cleanup already disposed it
and a plain return is correct.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Bugfix: Let a cancelled keyed open clear its own retained share key.

The round-2 fix's blanket cancelled-bail before the post-open clears
discarded positive knowledge: reaching that line means the open
*resolved*, i.e. the server durably confirmed the redemption (nothing in
disposal reverts it). A confirmed-then-cancelled attempt (unmount, stub
swap, retry) left the identity-stamped sessionStorage entry behind --
the stamp is deliberately not cancelled-gated -- and every replay path
later re-redeemed the still-live link, silently restoring access after
an owner removal.

Clearing is now attempt-owned: clearRetainedShareKey takes an `onlyKey`
and no-ops (no removal, no generation bump) when the stored entry
carries a different key, so a newer capture's retention and in-flight
stamp survive -- which is what keeps the round-2 superseded-attempt test
passing unchanged -- while a matching or absent entry is cleared and its
pending stamp voided even after cancellation. The absent-entry bump is
deliberate fail-toward-security; its residual (voiding a concurrent
newer attempt's in-flight stamp) is documented with the recovery being
a re-click of the invite link.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Bugfix: Void a cleared share key's own pending stamp without touching other keys'.

The round-3 attempt-owned clear (clearRetainedShareKey with onlyKey) returned
without any invalidation when a different key occupied the entry -- so a
superseded attempt A whose open the server confirmed, but whose identity
stamp was still parked in whoami(), never voided that stamp: it landed late,
overwrote the newer attempt B's entry with A's *confirmed* key, and a later
mount replayed it -- re-redeeming the still-live link after an owner removal.
The generations were per-workspace, so A's stamp could not be voided without
also voiding B's.

Add a per-(workspace, key) generation tier: beginRetainedShareKeyWrite now
records the key it will stamp, commitRetainedShareKeyWrite checks all three
tiers, and an onlyKey clear always bumps exactly its own key's generation --
voiding the calling attempt's stamp even when a different key occupies the
entry -- while removing the entry only when it is absent or matching, and
leaving the workspace generation alone. That last part also retires round 3's
documented absent-entry residual: an attempt-owned clear can no longer void a
concurrent newer attempt's in-flight stamp.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Bugfix: Bail a cancelled attempt before it mutates newer retention.

In the retained-storage path, a cancelled attempt parked in whoami() resumed
and mutated retention before the pre-open cancelled check: the identity-match
branch re-armed the in-memory ref over a newer attempt's capture, and the
mismatch branch called the unscoped clearRetainedShareKey(id) -- sweeping a
newer attempt's entry and, via the workspace-generation bump, permanently
voiding its in-flight identity stamp.

Bail immediately after the identity resolves: a cancelled attempt no longer
owns retention, so it must neither re-arm the ref nor judge an entry that may
have been replaced while it was parked. And scope the identity-mismatch sweep
to the key this branch actually read and judged (clearRetainedShareKey(id,
retained.key), from the previous commit's key-scoped clears), so a newer
capture's different-key entry and stamp survive even if the branch is ever
reached with stale data.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Bugfix: Scope attempt-owned share-key clears by capture, not raw key.

Attempt-owned clears (the post-open success clear and the identity-
mismatch sweep) identified their retention by (workspaceId, raw key), so
two captures of the *same* invite key collided: after a same-tab user
switch, user A's disposed open of key K resolving late would remove user
B's freshly captured entry for the same K and permanently void B's
in-flight identity stamp (the per-(workspace, key) write generation was
shared), dead-ending B's retry on the access-denied page. An
availability bug only -- clearing is the fail-safe direction.

Each fragment capture now gets a unique captureId, stored in the entry,
the in-memory ref, and the write token. Attempt-owned clears bump that
capture's own generation and remove the entry only when it carries the
same captureId, so a same-key successor capture survives both the
removal and the stamp-voiding. Workspace-scoped and global clears are
unchanged.

The stored entry shape gains a required captureId with no migration:
the v2 format exists only on this branch, so entries without one simply
read as absent.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Mitigate duplicated-tab replay of a retained share key.

Browsers copy sessionStorage into a duplicated tab, so a retained
share-key entry cleared in the original tab lives on in the copy: after
a successful redemption and a later collaborator removal, the
duplicate's revocation-restart reconnect would silently re-redeem the
still-live link, undoing the removal.

Two frontend mitigations bound this without touching the kernel API
surface. Entries now expire 15 minutes after their identity stamp is
written (the legitimate failed-open retry/reload fits well inside that;
a copy replaying after a later removal does not), and clears propagate
across same-origin tabs over a BroadcastChannel -- capture-scoped
clears, which a duplicate's copied entry answers to because it shares
the original's captureId, and the logout sweep, since tabs share the
login session. Workspace-scoped clears name no capture and deliberately
stay local, so an independent sibling capture still legitimately
retrying is never blanket-cleared.

Documented residual: a duplicate discarded or unloaded at broadcast
time that reactivates within the TTL can still replay once. The link
itself stays multi-use server-side (docs/sharing.md already carries the
matching manual re-redeem residual); a single-use server-side retry
capability would close both and remains a possible kernel-side
follow-up.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Restate the retained-share-key rationale for one-step redemption.

Comments and the plan doc still described two-phase redemption: a failed
open reverting the redemption server-side, so a retry had to re-send the
key, and success "confirming" it. Under one-step redemption (#340) the
edge is real the moment the server redeems, so a failure after that
point retries keylessly and nothing is ever reverted or confirmed.

The mechanism is unchanged and still earns its keep: an open can fail
*before* the redemption lands (a transport failure, a server throw ahead
of the redemption, an attempt superseded before issuing), and the client
cannot distinguish that from a post-redemption failure, so it retains
the key on every failure -- replaying a key whose edge already exists is
a server-side no-op. Prose only; no behavior change.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* Bugfix: Supersede an older capture's pending share-key stamp on a newer capture.

Write tokens tracked clears but not newer captures, so two captures for
one workspace with identity stamps in flight raced on the entry: when
the older capture's whoami() resolved last, its stamp overwrote the
newer capture's entry. Nothing had cleared, so no generation moved --
the older key (spent or not) became what a reload replayed under the
newer capture's session.

Starting a capture now bumps the workspace generation before taking its
token, so every older pending stamp for that workspace fails its
workspace check at commit time. The newest capture owns the slot
outright, whether or not the older attempt ever succeeded or cleared.
Other workspaces' pending stamps are untouched, and the per-capture tier
keeps its job: it is still what lets the newest capture's own success
clear void its stamp without voiding a later capture's.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Bugfix: Let a broadcast share-key clear reach a live duplicate's in-memory key.

The cross-tab clear broadcast swept a duplicated tab's sessionStorage
copy but not the two other places the same tab could still hold the
key: the hook's retainedShareKeyRef, re-armed from the copied entry
(same captureId), and a local the reload path had read the entry into
before parking in its identity await. "Try again" on the same stub
replayed the ref, and the resumed await attached the stale local -- so a
live duplicate re-redeemed the cleared key exactly as if nothing had
been broadcast.

Clears now notify subscribers (subscribeToRetainedShareKeyClears):
capture-scoped clears and the logout sweep, local and received alike,
with a capture-scoped clear reported whether or not a stored entry
matched, since the ref is a separate tier. Workspace-scoped clears stay
unreported: they name no capture, are never broadcast, and the hook
drops its own ref before issuing them. A listener's throw cannot break
the clear. The hook subscribes and drops its ref on a clear naming its
capture (or on the sweep), leaving a newer local capture with a
different id untouched; and the reload path re-reads storage after the
identity await, proceeding keylessly when the entry it judged has since
been swept (sibling broadcast, logout, or TTL).

The residual shrinks to what the module header already documents: only
a duplicate unloaded at broadcast time that reactivates within the TTL
can still replay once.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Bugfix: Remove an older capture's stored share-key entry when a newer capture begins.

Starting a capture superseded the older capture's *pending* stamp
(workspace generation bump) but left its already-committed entry in
storage until the new capture's own stamp landed. For one identity
round trip the slot held the older key, so a reload inside that window
replayed the older capture instead of the one just taken -- "the newest
capture owns the slot" was true of the stamp but not of the entry.

beginRetainedShareKeyWrite now also removes the workspace's stored
entry, after bumping the generation and before returning the token, so
the slot is empty rather than stale until the new stamp lands. The
removal is local only: a sibling tab's entry under the same workspace
is its own capture, or a duplicate's copy of an older one that the
older capture's own success clear reaches. Other workspaces' entries
and pending stamps, and the per-capture tier, are untouched.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Bugfix: Broadcast the clear of a share-key entry skipped by an unresolvable identity.

The reload path leaves a retained entry in place when whoami() rejects
(identity unknown, so the key is neither attached nor discarded). If the
keyless open then succeeds, the follow-up clear at the success site was
workspace-scoped -- and that scope names no capture, so it is never
broadcast. A duplicated tab's copy of the same entry (same captureId),
and a live duplicate's re-armed in-memory ref, survived the original's
success and could replay the still-live link after an owner removal.
Narrow -- it needs whoami() to fail while openGadget on the same stub
succeeds -- but it left one success path outside the "broadcast reaches
every tier" claim.

The keyless success now reads whatever entry is still stored for the
workspace and clears it by capture id first, which is the scope that
reaches siblings, before issuing the workspace-scoped clear that voids
the workspace's in-flight stamps. The leftover can only be the entry
this attempt read but could not judge, or nothing: a newer local
capture would have cancelled this attempt before it got here. Only
duplicates of this tab share the capture id, so the broadcast cannot
touch an independent sibling's capture, and a wrongly cleared key costs
a re-click of the link.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Reword the restricted-data sharing warning to match role-scoped verification.

The share modal's banner told an owner that invitees "must be verified
to have access to the same data". The server's check is narrower:
verification is scoped to the recipient's role (build recipients are
checked against every account-requiring connection present, use
recipients only against connections a gadget binds or an enabled hook
feeds), and producers that were never bound, are unbound, or were
removed after the read fall outside it -- their persisted output is
visible to anyone who can open the workspace (docs/observers.md edge
case 4). The banner is the copy an owner reads while deciding to share,
so it now states the guarantee actually made, and the disclosure that
goes with it: invitees verify their own access to the connections the
workspace uses at their access level, and anything already saved is
visible to everyone who can open it. The "Recipient verification" panel
beneath it already lists those connections per level. Prose only; no
server change.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Bugfix: Broadcast the clear of a share-key entry displaced by a newer capture.

beginRetainedShareKeyWrite removed the displaced entry locally only, on the
reasoning that a duplicated tab's copy of it would be reached by the displaced
capture's own success clear. That only holds if the displaced open ever
succeeds somewhere. Once a newer capture displaces it in the original tab, the
original's attempt is gone, so the only remaining clear path for the displaced
capture is the duplicate redeeming it itself. A duplicate whose own attempt
failed transiently keeps the copy; the newer capture's success clear names the
newer capture and misses it; and a reconnect in the duplicate inside the TTL
replays the displaced key after an owner may have removed the collaborator.

Clear the displaced entry by its capture id instead, which broadcasts. Capture
ids are per-capture UUIDs, so the clear can only reach copies of this tab's
entry, never an independent sibling capture, and this tab's own hook ref
already holds the new capture before the begin runs, so the local notification
drops nothing. The bare removal stays behind it for an entry the reader rejects
(malformed or v1), which no capture-scoped clear can name.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Bugfix: Clear an unjudged retained share key when its keyless open confirms after cancellation.

The identity-unknown reload path leaves a stored entry it could neither
attach nor judge, and the keyless success at the end of the attempt is
what discards it. A cancellation landing while the metadata subscribe
was in flight skipped that clear, even though the subscribe resolving
proves the keyless open succeeded (the pipelined call would have
rejected otherwise), so the spent entry survived for a later reload to
replay against the still-live link after an owner removal. Mirror the
keyed path's confirm-after-cancel clear, scoped to the capture this
attempt actually read so a newer attempt's entry and in-flight stamp
survive.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Bugfix: Leave another workspace's in-memory share key alone on a keyless success.

By the time a keyless open succeeds, any in-memory ref for that
workspace is already gone (dropped on a foreign stub, cleared by the
keyed success, or superseded by a newer capture cancelling the
attempt), so the unconditional ref clear could only ever drop a
different workspace's retention: capture a key for A, have A's open
fail transiently, open B keylessly, and A's same-stub retry lost its
key. Nothing about B's success says anything about A's key, and every
other ref clear in the hook is already scoped by id. Guard this one too.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Trim the retained-share-key comments.

Comments only. The rationale blocks in retainedShareKeys.ts and
useWorkspaceOpen.ts had grown by accretion over the bugfix series and
repeated themselves across sites; each is cut to what a reader needs at
that site, with the model and residuals stated once in the module and
ref headers.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

* Remove client-side share-key retention.

Reverts the retained-share-key series to the pre-series state: the
`#share=` fragment is stripped on open and sent once, and a first open
that fails before the server redeems the key is retried keylessly, so
the user re-clicks the invite link. Retaining the key across retries,
reconnects and reloads reopened replay-after-removal and cross-user
paths that took identity stamps, generation tokens, a TTL and cross-tab
broadcasts to close, and still left residuals (a mangled fragment stuck
until the TTL, a lost role upgrade), all to save one link re-click.

Restores useWorkspaceOpen.ts, its test, useAuth.ts, its test and
docs/sharing.md to their base versions, deletes retainedShareKeys.ts
and its test, and drops the retention items from the sharing plan.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>